MySQL 中的行锁

MySQL 的行锁是一种锁机制，用于控制对数据库表中单行或多行数据的并发访问和修改。行级锁允许多个会话同时读取同一表的不同行，但在写操作时会对所涉及的行进行锁定，以防止其他会话对相同行进行并发修改。

提示

MySQL 的行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁，比如 MyISAM 引擎就不支持行锁。不支持行锁意味着并发控制只能使用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务并发度。InnoDB 是支持行锁的，这也是 MyISAM 被 InnoDB 替代的重要原因之一。

以下是一个使用行锁的示例（这里是手动加锁）：

假设有一个名为 products 的表，用于存储产品信息，其中包含 id、name 和 quantity 等列。

会话 A 和会话 B 同时执行如下事务：

会话A：

START TRANSACTION;
SELECT * FROM products WHERE id = 1; -- 读取产品1的信息

会话B：

START TRANSACTION;
SELECT * FROM products WHERE id = 1; -- 读取产品1的信息

在这个示例中，两个会话尝试读取相同 id 为 1 的产品信息。如果没有行级锁的存在，它们可以并发地读取相同的行。

然而，当会话 A 读取产品 1 的信息时，会自动获取对该行的行级共享锁。这将阻止其他会话在会话 A 释放锁之前修改该行。

现在，会话 B 也尝试读取产品 1 的信息。由于该行已经被会话 A 锁定，会话 B 必须等待会话 A 释放锁才能继续执行。

如果会话 A 执行如下操作后释放锁：

UPDATE products SET quantity = quantity + 1 WHERE id = 1; -- 对产品1的数量进行更新
COMMIT;

随后，会话 B 才能获取对产品 1 的行级共享锁，并读取最新的产品信息。

通过行级锁，MySQL提供了更细粒度的并发控制，允许在多个会话同时读取表的不同行，同时保护写操作的数据一致性。这样可以提高并发性能和数据的并发访问能力。

行锁实现方式

InnoDB 行锁是通过给索引上的索引项加锁来实现的，这一点 MySQL 与 Oracle 不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB 这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB 才使用行级锁，否则，InnoDB 将使用表锁！

不论是使用主键索引、唯一索引或普通索引，InnoDB 都会使用行锁来对数据加锁。

只有执行计划真正使用了索引，才能使用行锁：即便在条件中使用了索引字段，但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价来决定的，如果 MySQL 认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB 将使用表锁，而不是行锁。

因此，在分析锁冲突时，别忘了检查 SQL 的执行计划（可以通过 explain 检查 SQL 的执行计划），以确认是否真正使用了索引。

由于 MySQL 的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然多个 session 是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的（后使用这些索引的 session 需要等待先使用索引的 session 释放锁后，才能获取锁）。应用设计的时候要注意这一点。

两阶段锁的概念

在下面的操作序列中，事务 B 的 update 语句执行时会是什么现象呢？假设字段 id 是表 t 的主键

这个问题的结论取决于事务 A 在执行完两条 update 语句后，持有哪些锁，以及在什么时候释放。你可以验证一下：实际上事务 B 的 update 语句会被阻塞，直到事务 A 执行 commit 之后，事务 B 才能继续执行。

知道了这个答案，你一定知道了事务 A 持有的两个记录的行锁，都是在 commit 的时候才释放的。

也就是说，在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。

知道了这个设定，对我们使用事务有什么帮助呢？那就是，如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。我给你举个例子。

假设你负责实现一个电影票在线交易业务，顾客A要在影院B购买电影票。我们简化一点，这个业务需要涉及到以下操作：

从顾客A账户余额中扣除电影票价；
给影院B的账户余额增加这张电影票价；
记录一条交易日志。

也就是说，要完成这个交易，我们需要 update 两条记录，并 insert 一条记录。当然，为了保证交易的原子性，我们要把这三个操作放在一个事务中。那么，你会怎样安排这三个语句在事务中的顺序呢？

试想如果同时有另外一个顾客C 要在影院 B 买票，那么这两个事务冲突的部分就是语句 2 了。因为它们要更新同一个影院账户的余额，需要修改同一行数据。

根据两阶段锁协议，不论你怎样安排语句顺序，所有的操作需要的行锁都是在事务提交的时候才释放的。所以，如果你把语句 2 安排在最后，比如按照 3、1、2 这样的顺序，那么影院账户余额这一行的锁时间就最少。这就最大程度地减少了事务之间的锁等待，提升了并发度。

好了，现在由于你的正确设计，影院余额这一行的行锁在一个事务中不会停留很长时间。但是，这并没有完全解决你的困扰。

如果这个影院做活动，可以低价预售一年内所有的电影票，而且这个活动只做一天。于是在活动时间开始的时候，你的 MySQL 就挂了。你登上服务器一看，CPU 消耗接近 100%，但整个数据库每秒就执行不到 100 个事务。这是什么原因呢？

这里，我就要说到死锁和死锁检测了。

死锁和死锁检测

当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。这里我用数据库中的行锁举个例子。

这时候，事务 A 在等待事务 B 释放 id=2 的行锁，而事务 B 在等待事务 A 释放 id=1 的行锁。事务 A 和事务 B 在互相等待对方的资源释放，就是进入了死锁状态。当出现死锁以后，有两种策略：

一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

在 InnoDB 中，innodb_lock_wait_timeout 的默认值是 50s，意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过 50s 才会超时退出，然后其他线程才有可能继续执行。对于在线服务来说，这个等待时间往往是无法接受的。

但是，我们又不可能直接把这个时间设置成一个很小的值，比如 1s。这样当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢？所以，超时时间设置太短的话，会出现很多误伤。

所以，正常情况下我们还是要采用第二种策略，即：主动死锁检测，而且 innodb_deadlock_detect 的默认值本身就是 on。主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是它也是有额外负担的。

你可以想象一下这个过程：每当一个事务被锁的时候，就要看看它所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待，也就是死锁。

那如果是我们上面说到的所有事务都要更新同一行的场景呢？

每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是 O(n) 的操作。假设有 1000 个并发线程要同时更新同一行，那么死锁检测操作就是 100万这个量级的。虽然最终检测的结果是没有死锁，但是这期间要消耗大量的CPU资源。因此，你就会看到 CPU 利用率很高，但是每秒却执行不了几个事务。

根据上面的分析，我们来讨论一下，怎么解决由这种热点行更新导致的性能问题呢？问题的症结在于，死锁检测要耗费大量的 CPU 资源。

一种头痛医头的方法，就是如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉。但是这种操作本身带有一定的风险，因为业务设计的时候一般不会把死锁当做一个严重错误，毕竟出现死锁了，就回滚，然后通过业务重试一般就没问题了，这是业务无损的。而关掉死锁检测意味着可能会出现大量的超时，这是业务有损的。

另一个思路是控制并发度。根据上面的分析，你会发现如果并发能够控制住，比如同一行同时最多只有 10 个线程在更新，那么死锁检测的成本很低，就不会出现这个问题。一个直接的想法就是，在客户端做并发控制。但是，你会很快发现这个方法不太可行，因为客户端很多。我见过一个应用，有 600 个客户端，这样即使每个客户端控制到只有 5 个并发线程，汇总到数据库服务端以后，峰值并发数也可能要达到 3000。

你可以考虑通过将一行改成逻辑上的多行来减少锁冲突。还是以影院账户为例，可以考虑放在多条记录上，比如 10 个记录，影院的账户总额等于这 10 个记录的值的总和。这样每次要给影院账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成原来的 1/10，可以减少锁等待个数，也就减少了死锁检测的 CPU 消耗。

这个方案看上去是无损的，但其实这类方案需要根据业务逻辑做详细设计。如果账户余额可能会减少，比如退票逻辑，那么这时候就需要考虑当一部分行记录变成 0 的时候，代码要有特殊处理。

共享锁和排他锁

InnoDB 存储引擎实现了如下两种标准的行级锁：

共享锁（S Lock），允许事务读一行数据。
排他锁（X Lock），允许事务删除或更新一行数据。

提示

共享锁和排他锁（Shared and Exclusive Locks），其实就是常说的读锁和写锁。共享锁和排他锁是标准的实现行级别的锁。举例来说，当给 select 语句应用 lock in share mode 或 for update 或者更新某条记录时，加的都是 行级别的锁。

如果一个事务 T1 已经获得了行 r 的共享锁，那么另外的事务 T2 可以立即获得行 r 的共享锁，因为读取并没有改变行 r 的数据，称这种情况为锁兼容（Lock Compatible）。

但若有其他的事务 T3 想获得行 r 的排他锁，则其必须等待事务 T1、T2 释放行 r 上的共享锁一这种情况称为锁不兼容。

表 6-3 显示了共享锁和排他锁的兼容性。

从表 6-3 可以发现 X 锁与任何的锁都不兼容，而 S 锁仅和 S 锁兼容。需要特别注意的是，S 和 X 锁都是行锁，兼容是指对同一记录（row）锁的兼容性情况。

具体如下图所示

如下简单介绍下用法

1、除了显式加锁 lock in share mode 或 for update 的情况，其他情况下的加锁与解锁都无需人工干预。

-- 在锁之前得先关闭自动提交
set autocommit = 0;

-- MySql加共享锁的命令：（sql语句） + lock in share mode;
-- 手动加锁方式 
select * from student where id = 1 LOCK IN SHARE MODE;

-- 释放锁
commit / rollback;

或者

-- 手动加锁
select * from student where id=1 FOR UPDATE;

2、InnoDB 所有的行锁算法都是基于索引实现的，锁定的也都是索引或索引区间；

共享锁（S锁）

又称为读锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，允许其他人读取资源，但是禁止其他人删除，修改资源

-- 在锁之前得先关闭自动提交
set autocommit = 0;

-- MySql加共享锁的命令：（sql语句） + lock in share mode;
-- 手动加锁方式 
select * from student where id = 1 LOCK IN SHARE MODE;

-- 释放锁
commit / rollback;

一般用于锁住某行数据不被修改，例如不希望订单信息被修改就可以给它加上这种锁

如下使用共享锁的实例

查看输出结果

与行级别的共享锁和排他锁类似的，还有表级别的共享锁和排他锁。如 LOCK TABLES ... WRITE/READ 等命令，实现的就是表级锁。

排他锁（X锁）

又称为写锁，排他锁不能与其他锁并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的锁（共享锁、排他锁），只有该获取了排他锁的事务是可以对数据行进行读取和修改。

加锁释锁方式:

自动: delete / update / insert 默认加上 X锁;

-- 手动加锁
select * from student where id=1 FOR UPDATE;

行锁的三种算法

InnoDB 存储引擎有 3 种行锁的算法，其分别是：

Record Lock：记录锁，单个行记录上的锁
Gap Lock：间隙锁，锁定一个范围，但不包含记录本身，是为了防止同一事务的两次当前读，出现幻读的情况。
Next-Key Lock：就是 Gap Lock + Record Lock，锁定一个范围，并且锁定记录本身

补充：在 Read Committed 隔离级别下，不会使用间隙锁。这里对官网补充一下，隔离级别比 Read Committed 低的情况下，也不会使用间隙锁，如隔离级别为 Read Uncommited 时，也不存在间隙锁。当隔离级别为 Repeatable Read 和 Serializable 时，就会存在间隙锁。

Record Lock：单个记录的锁

记录锁，它封锁索引记录，作用于唯一索引上，如下图所示：

select * from t where id = 4 for update;

它会在 id=4 的索引记录上加锁，以阻止其他事务插入，更新，删除 id=4 的这一行。

记录锁出现条件：精准条件命中，并且命中的条件字段是唯一索引；

例如：

-- 这里的id是唯一索引。
update user_info set name='张三' where id=1;

Record Lock 总是会去锁住索引记录，如果 InnoDB 存储引擎表在建立的时候没有设置任何一个索引，那么这时 InnoDB 存储引擎会使用隐式的主键来进行锁定。

记录锁的作用：加了记录锁之后可以避免数据在查询的时候被修改的重复读问题，也避免了在修改的事务未提交前被其他事务读取的脏读问题。

Gap Lock：间隙锁 ⭐

间隙锁，锁定一个范围，但不包括记录本身。GAP 锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况。

今天分析的问题都是在可重复读隔离级别下的，间隙锁是在可重复读隔离级别下才会生效的。所以，你如果把隔离级别设置为读提交的话，就没有间隙锁了。

行锁只能锁住行，但是新插入记录这个动作，要更新的是记录之间的 “间隙”。因此，为了解决幻读问题，InnoDB 只好引入新的锁，也就是间隙锁（Gap Lock）。

CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `c` int(11) DEFAULT NULL,
  `d` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `c` (`c`)
) ENGINE=InnoDB;

insert into t values(0,0,0),(5,5,5),
(10,10,10),(15,15,15),(20,20,20),(25,25,25);

顾名思义，间隙锁，锁的就是两个值之间的空隙。表 t，初始化插入了 6 个记录，这就产生了 7 个间隙。

这样，当你执行 select * from t where d = 5 for update 的时候，就不止是给数据库中已有的 6 个记录加上了行锁，还同时加了 7 个间隙锁。

这样就确保了无法再插入新的记录。

也就是说这时候，在一行行扫描的过程中，不仅将给行加上了行锁，还给行两边的空隙，也加上了间隙锁。

跟间隙锁存在冲突关系的，是 “往这个间隙中插入一个记录” 这个操作。间隙锁之间都不存在冲突关系。

这句话不太好理解，举个例子（手动加锁来模拟）：

这里 session B 并不会被堵住。

因为表 t 里并没有 c = 7 这个记录，因此 session A 加的是间隙锁 (5, 10)。而 session B 也是在这个间隙加的间隙锁。它们有共同的目标，即：保护这个间隙，不允许插入值。但，它们之间是不冲突的。

Next-Key Lock：临键锁 ⭐

Next-Key Lock 是结合了 Gap Lock 和 Record Lock 的一种锁定算法，在 Next-Key Lock 算法下，InnoDB 对于行的查询都是采用这种锁定算法（其实就是会动态的选择 Gap Lock 和 Record Lock 来优化加锁操作）。

临键锁是 InnoDB 的行锁默认算法，它是记录锁和间隙锁的组合，临键锁会把查询出来的记录锁住，同时也会把该范围查询内的所有间隙空间也会锁住，再之它会把相邻的下一个区间也会锁住。

它的封锁范围，既包含索引记录，又包含索引之前的区间，即：

（负无穷大，1]，（2,4]，（5,7]，（8,11]，（12，无穷大]

在事务A中执行：

UPDATE table SET name = 'javaHuang' WHERE age = 4;

SELECT * FROM table WHERE age = 4 FOR UPDATE;

这两个语句都会锁定 (2,4]，(4,7) 这两个区间。

即， InnoDB 会获取该记录行的临键锁，并同时获取该记录行下一个区间的间隙锁。

临键锁的作用：结合记录锁和间隙锁的特性，临键锁避免了在范围查询时出现脏读、重复读、幻读问题。加了临键锁之后，在范围区间内数据不允许被修改和插入。

这里分析的问题都是在可重复读隔离级别下的，间隙锁是在可重复读隔离级别下才会生效的。所以，你如果把隔离级别设置为读提交的话，就没有间隙锁了。

总结：加锁规则

加锁规则里面，包含了两个 “原则”、两个 “优化” 和一个 “bug”。

原则 1：加锁的基本单位是 next-key lock。而 next-key lock 是前开后闭区间。
原则 2：查找过程中访问到的对象才会加锁。
优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。
优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。
一个 bug：唯一索引上的范围查询会访问到不满足条件的第一个值为止。

案例一：等值查询间隙锁

第一个例子是关于等值条件操作间隙：

由于表 t 中没有 id=7 的记录，所以用我们上面提到的加锁规则判断一下的话：

1、根据原则 1，加锁单位是 next-key lock，session A 加锁范围就是 (5,10]；

2、同时根据优化 2，这是一个等值查询 (id=7)，而向右最后一个值 id=10 不满足查询条件，next-key lock 退化成间隙锁，因此最终加锁的范围是 (5,10)。

所以，session B 要往这个间隙里面插入 id=8 的记录会被锁住，但是 session C 修改 id=10 这行是可以的。

案例二：非唯一索引等值锁

第二个例子是关于覆盖索引上的锁：

这里 session A 要给索引 c 上 c=5 的这一行加上读锁。

1、根据原则 1，加锁单位是 next-key lock，因此会给 (0,5] 加上 next-key lock。

2、要注意 c 是普通索引，因此仅访问 c=5 这一条记录是不能马上停下来的，需要向右遍历，查到 c=10 才放弃（因为是查找间隙，所以就是找到 5 的下一个值为止）。根据原则 2，访问到的都要加锁，因此要给 (5,10] 加 next-key lock。

3、但是同时这个符合优化 2：等值判断，向右遍历，最后一个值不满足 c=5 这个等值条件，因此退化成间隙锁 (5,10)。

4、根据原则 2 ，只有访问到的对象才会加锁，这个查询使用覆盖索引，并不需要访问主键索引，所以主键索引上没有加任何锁，这就是为什么 session B 的 update 语句可以执行完成。

但 session C 要插入一个 (7,7,7) 的记录，就会被 session A 的间隙锁 (5,10) 锁住。

lock in share mode 只锁覆盖索引，但是如果是 for update 就不一样了。执行 for update 时，系统会认为你接下来要更新数据，因此会 顺便给主键索引上满足条件的行加上行锁。

这个例子说明，锁是加在索引上的；同时，它给我们的指导是，如果你要用 lock in share mode 来给行加读锁避免数据被更新的话，就必须得绕过覆盖索引的优化，在查询字段中加入索引中不存在的字段。比如，将 session A 的查询语句改成

select d from t where c = 5 lock in share mode

案例三：主键索引范围锁

第三个例子是关于范围查询的。

现在我们就用前面提到的加锁规则，来分析一下 session A 会加什么锁呢？

开始执行的时候，要找到第一个 id=10 的行，因此本该是 next-key lock (5,10]。
根据优化 1，主键 id 上的等值条件，退化成行锁，只加了 id=10 这一行的行锁。
范围查找就往后继续找，找到 id=15 这一行停下来，因此需要加 next-key lock (10,15]。

所以，session A 这时候锁的范围就是主键索引上，行锁 id=10 和 next-key lock (10,15]。这样，session B 和 session C 的结果你就能理解了。

这里你需要注意一点，首次 session A 定位查找 id=10 的行的时候，是当做等值查询来判断的，而向右扫描到 id=15 的时候，用的是范围查询判断。